Why is this nullable? per Effective Java, empty collections are preferred.

There is a difference in this case:

• null means 'do not override the default settings`.
• An empty set means 'override the default settings by disabling retrying'.

I've added that to the documentation of ApiCallContext#getRetryableCodes().

The way the new constructor is implemented in RetryAlgorithm (the one which implementation you listed in the comment) seems being kind of against OOP principles, since the constructor does accept a generic interface, but then instantiates the specific instances of the interface instead. I understand that sometimes we may need to do something like this, but I'm not sure it is that case.

Looks like the Ignore* classes exist only because RetryAlgorithm implementation changed the aggregated fields type to the context-aware interfaces:

  private final ResultRetryAlgorithmWithContext<ResponseT> resultAlgorithm;
  private final TimedRetryAlgorithmWithContext timedAlgorithm;

A the same time this PR adds the full copy of all the existing methods in RetryAlgorithm but with the context extra parameter now. I.e. this means that this class can be used eitehr as context-aware one or as context-unaware, but not in both different context. WDYT about instead of adding the new Ignore* classes, just make RetryAlgorithm just have both types of algorithms aggregated:

  private final ResultRetryAlgorithm<ResponseT> resultAlgorithm;
  private final TimedRetryAlgorithm timedAlgorithm;
  private final ResultRetryAlgorithmWithContext<ResponseT> resultAlgorithmWithContext;
  private final TimedRetryAlgorithmWithContext timedAlgorithmWithContext;

And use each of the algorithms accordingly depending in which method of REtryAlgorithm class it is used (context-aware or not).

In general, I'm just trying to avoid having classes like IgnoreRetryingContextReulstRetryAlgorithm because they are obviously a hack (even check the name, it is too long an unreadable). So here I'm trying to trade it to simply having context-aware fields as null for older constructor, and it is ok to throw an exception if context-aware methods are used for RetryAlgorithm initialized in legacy way.

Also, as you suggest in your comments, please go ahead and deprecate the old constructor for RetryAlgorithm and relevant stuff (maybe even the old context-unaware methods as well).

Please don't use access modifiers (public) on interface methods, as they are redundant.

can you call createNextAttempt() (no context one) here for consistency with the shouldRetry implementation?

Optional (but please consider doing it). It seems like a lot of method duplication is happening here (context-aware vs context-unaware methods). Please consider replacing documentation for every context-unaware method in all of the classes with a link to the context-aware one with the explanation, that this one (context-unaware one) is doing the same but without the context. This will not only can make it shorter in terms of docs, but will also provide a clear picture to the users of these classes why there are both types of methods (which may be really confusing).

Also, please consider deprecating the context-unaware methods.

1. I've updated the documentation of the context-unaware interfaces and their methods to reference the context-aware versions.
2. I've deprecated all the context-unaware methods

Can we make these methods (context-aware and context-unaware methods in streaming algorithm) call each other, like it is done in the non-streaming versions? This is to reduce code dupliation and make the implementation more robust in general.

Done (this is now possible as the context-aware methods accept null values for the context)

Can we mark these new methods as BetaApi. This an addition to a fundamental interface, whatever we add here we will have to stick with for a really long time.

Done

Sorry for confusing with my @Deprecate request. I think we should just mark the methods and constructors in RetryAlgorithm class as deprecated (the old ones) and make sure that the non-deprecated methos (new ones) are called by the deprecated methods (which is what is happening now, so it is all good), otherwise we will be using our own deprecated methods to implement non-deprecated methods, which is wrong.

For the rest of it, please undeprecate the methods back, as is is clear that RetryAlgorithm cannot be used in both contexts (as context-aware and as unaware), but the actual interfaces (timed and result) kind of still potentially can have meaningful implementation for all the methods, but most importantly it is too much deprecation happening on interface level, I'm afraid we are going to get too many deprecaton warnings.

So to summarize: deprecate the old constructor and methods in RetryAlgorithm class, undeprecate the other stuff (the TimedRetryAlgorithm and ResultRetryAlgorithm methods - in both places, the @Deprecated annotation and @deprecated java doc element, maybe adding in the general java doc section of each element a notion that the other method should be preferred, but it does not mean it is deprecated in a strict sense of it).

Done